Facing the need for a hidden service I2P, Most are forced to use the services of hosting providers. For example, because it is not possible to provide good resource uptime on a home computer. Using data center services implies trust: we hope that the staff will not abuse their position and that someone will not try to steal data from the disks.
Alas, confidence in a serious project alone is not enough, because even a banal hacking of the system from the outside can never be ruled out. There is no such thing as absolute security, but after any incident you probably want to recover as quickly as possible. This manual will tell you how to use temporary keys so that the address of your hidden resource cannot be stolen even if the server is compromised.
Formation of an intranet I2P address
When creating a server tunnel that brings a local service to a hidden network, you must specify a file with keys (if a non-existent one is specified, a new file with random keys is created).
The key file contains cryptographic identifiers. A total of 391 bytes of public information and secret keys that are not published. The hash of the block of public information contained in the key file forms the intranet address.
Both long addresses “.b32.i2p” and short domain names in the “.i2p” zone are bound to the full address (391 bytes of public information), so the given key file is critical: if we lose it, we lose control over address. If an attacker deploys another server tunnel with our key, the operation of the original hidden service will be disrupted at best, and at worst, the attacker will be able to pass off his resource as original for some users whose router finds his lysset first.
Lissets
Server endpoints, that is, hidden services of the I2P network, publish information about themselves on floodfills so that other network participants can find them. This information is called a LeaseSet and includes a complete set of cryptographic identifiers - the full address (391 bytes), as well as information about incoming tunnels. The search for a LeaseSet occurs using a domain name derived from the keys. If the floodfill has the required LeaseSet, the client receives information to communicate with the endpoint.
secure key storage
I2P has the concept of offline keys, which allows you to store permanent keys in a secure location. In other words, the main key is stored in a secure place, and the server uses a temporary one that expires after a specified number of days. If it is compromised, after a specified period of validity, you can confidently say that your network address again belongs only to you.
This feature is implemented by the signing key. The main public key is included in the array of the full address and is directly involved in the formation of the intranet domain. When using the offline keys feature, a temporary signing key is created and signed with the primary key. A special flag is present in the published LeaseSet of a server endpoint that uses a temporary key. The user who receives such a LeaseSet verifies the validity of the temporary key, which is also attached to the LeaseSet, using the endpoint's primary signing key. If the signature is normal, a standard session is established, within which the temporary key is given the same trust as the main one included in the full endpoint address.
A tool for creating temporary keys is included in the set i2pd-tools. The utility is called offlinekeys and has the following order of accepted parameters: <output file> <keys file> <signature type> <days>
. The last two parameters can be omitted, specifying only the output file and existing keys.
Without explicit indication signature type, the default is ED25519-SHA512 (code 7), and the expiration date is 365 days, i.e. a year. The type of signature can be specified either in code or in words.
After the file with temporary keys has been created, it can be uploaded to the server and used in its usual form. The main thing is not to forget to update the keys on time. You can also write a script that automates the process of updating keys on a remote server.